A trusted execution environment (TEE) is an environment where sensitive code can be executed in isolation from a so-called “rich OS” (e.g., Linux, Windows). In some ARM-based mobile devices, a TEE is realized based on the ARM TRUSTZONE technology, which is a hardware-based technology that allows security sensitive code to be executed in isolation from other less security sensitive code on the same physical CPU (“TRUSTZONE” is a registered trademark of the ARM Corporation). This is realized by the CPU having a state indicating if the CPU is executing in a so-called “secure world” or in a “normal world.” The state is propagated on busses to memories and other hardware blocks. Hardware which has the capability to utilize this state is called “TRUSTZONE aware.” Isolation is achieved by the fact that secure slaves, such as secure memory, can only be accessed by secure masters such as DMA (“Direct Memory Access”) in the secure world, or a CPU executing in the secure world. There is a special CPU instruction to switch between the two worlds, which triggers an exception to a certain address where the code to switch is located, called the “monitor.” There is a special CPU mode called secure monitor mode in which the switch can be made.
The applications executed within the TEE are called Trusted Applications (TAs). Trusted Application functions (e.g., services) can be called from rich OS applications. The TEE framework that enables this is shown in the computing device 10 of FIG. 1, which includes a separate Rich Execution Environment (REE) 12 and Trusted Execution Environment (TEE) 14. A TEE client API 30 is called by the rich OS (i.e., the REE 12) to access trusted application services. The TEE driver 28, the monitor 32, and the TEE core 48 are involved in invoking the correct service within the TEE. Trusted applications 44 can call services from the TEE core 48 via the TEE Internal API 46. Examples of such services are cryptographic services, memory management services, and secure time services. There is also the TEE supplicant 36 which is a daemon in the rich REE 12 providing REE services to the TEE core 48, such as non-volatile storage.
The TEE client API and TEE Internal API are standardized within Global Platform (see “Global Platform TEE Client API V1.0” and “Global Platform TEE Internal API V1.0,” both available at http://www.globalplatform.org/). For secure time, the TEE Internal API 46 contains functions for handling a trusted application 44 persistent time. There is one function that allows the trusted application 44 to set (i.e., store) its own time reference (a “TA persistent time”) and another function that can be called to get the current time of the TA. An example of a trusted application that utilizes secure time is a Digital Rights Management (DRM) TA that needs to keep track of a time reference which is used to evaluate whether a DRM license has expired or not. The time reference may be obtained in a secure way from a license server when downloading the DRM license.
For each TA that has stored a time reference, the TEE 14 is responsible to keep track of the TA persistent time, a stored time reference of the TA persistent time, and detect any attempt to tamper with the TA persistent time. To achieve the highest protection level, the TEE specifications mandate that the TA persistent time is based on a TEE-controlled real-time clock and TEE controlled secure storage. The real-time clock must be out of reach of software attacks from the REE 12.
One known secure time solution for DRM stores the secure time as a time offset towards the real-time clock of the system. The secure time is obtained by reading the real-time clock and compensating according to the stored offset. Whenever the RTC of the system was modified, the offset was also modified accordingly to keep the secure time unchanged. This solution was used in closed OS products where no TEE was used and all code was digitally signed, verified before execution, and trusted to not make non-authorized modifications to the real-time clock or the offset. The offset was integrity protected using a chip individual key while stored in the non-volatile storage.
However, this solution is inadequate for that which is mandated by TEE secure time. With today's products based on Linux/Android, for example, in which more or less all device models can get rooted, the above solution does not apply. Linux/Android cannot be in control of the real-time clock, since Linux/Android cannot be trusted not to be hacked by the device user in order to manipulate the time.
Another known solution implemented hardware (HW) support to prevent a hacker from setting back the clock. In this solution, to set back the clock to a value smaller than the existing one, the value needed to be signed using a private key (RSA) typically available only at OEM customer service centers. The device hardware contained the corresponding public key needed to verify the signed value. Only a successfully verified value smaller than the current value of the real-time clock was accepted by the hardware. However, this solution is also inadequate. Despite its protection against unauthorized rollback of the real-time clock, it is very inflexible and puts restrictions on what time the user himself can set on his device without going to a service center. Thus, this solution also does not prevent unauthorized increase of the real-time clock.
A straight forward solution to achieve a secure time controlled by the TEE that cannot be manipulated by REE 12 would be to have two real-time clocks: one for the “secure world” for the TEE for secure time, and one for the “normal world” to store the user controlled time. This option, however, is expensive in terms of silicon space.